In a web environment, a user might need to gain access to multiple secure web sites. To do so, the user typically enters a user ID and password at a first web site and, upon validation of the ID and password, is admitted to the site. At this point, a token can be created that authenticates the identity of the user and authorizes the user to gain access to certain other secure web sites. If the user subsequently attempts to reach another secure web site that recognizes the token, the user would not be required to enter the ID and password again. Instead, the token is passed to the web site and, if the token is found to be valid, the user is automatically granted access based on information provided by the token. Such an arrangement can allow a user to move seamlessly among secure web sites without being aware of the passing of the token that is occurring in the background.
A similar approach can be used in an application environment when a user wishes to gain access to multiple secure applications. When the user signs on to a secure application, a token for the user can be created that allows the user to be automatically signed on to other secure applications that recognize the token. In a single sign-on arrangement such as this, when the user switches from one application to another, the token is automatically passed to the appropriate application. As an example, upon the user signing on to a secure J2EE application, a token might be created that verifies the user's identity and allows the user to be automatically signed on to a secure CORBA application. If the user switches from the J2EE application to the CORBA application, the token is automatically passed from the J2EE application to the CORBA application, which then reads the token and, if the token is valid, allows the user access.
In either of these approaches, the creation and passing of tokens is typically handled by proprietary, off-the-shelf authentication and authorization products that are specific to the applications in question. For example, in the case of the web environment, an authentication and authorization product residing in a web server might hide the user token in a session of a web browser. The token might take the form of a cluster of security information that is passed from one web site to another. The web sites themselves might not be aware of the contents of the cluster. Upon receiving a token, a web site would merely confirm its authenticity with the authentication and authorization product. Only the authentication and authorization product would have access to the contents of the cluster so that it would have the ability to create and verify the security information.
In a situation where multiple instances of a single type of application need to communicate with one another without human intervention, a token might not be used. For example, in a homogeneous environment of multiple J2EE applications, the first time one application calls another, the calling application, or client, might present credentials, such as an ID and password, to the called application, or server. The server checks the client's credentials and determines if the client is authorized to make the requested call.
Upon approval of the credentials, the server accepts the call. A context might then be created for further point-to-point communication between the two applications. On subsequent requests, the server can check the context, or container, to ensure that the client is authorized to communicate with the server. Thus, a connection between the two similar applications can remain open without the need for the client to present credentials with each call to the server.
In each of these situations, a user accessing multiple secure web sites in a web environment, a user accessing multiple secure applications in a heterogeneous application environment, and an application accessing another instance of the same application in a homogeneous application environment, a mechanism exists by which identifying information for a user or an application is presented only upon the first attempt by the user or the application to gain access to a secure web site or a secure application. Upon subsequent attempts, the mechanism automatically allows legitimate users or applications to have access to the secure web site or the secure application without the further presentation of credentials. However, other situations exist that require additional capability and functionality. For example, disparate secure applications may need to communicate directly with one another in a heterogeneous application environment.